Automated delivery device and method for delivering a package

ABSTRACT

A ground transporter transports a package to a package recipient location and receives a token from a token recipient, wherein receiving the token represents a verification that the ground transporter has moved to the package recipient location. The ground transporter is configured, if the token is received, to deliver the package at the package recipient location.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. application Ser. No.16/143,534, filed on Sep. 27, 2018, the entirety of which isincorporated herein by reference.

TECHNICAL FIELD

Exemplary implementations described herein generally relate to automateddelivery devices and methods for delivering a package.

BACKGROUND

Today, package delivery goes largely untrusted. Manual delivery methodstake on at least two forms: a recipient needs to be present at the timeof delivery to sign and receive the package or a package can bedelivered unattended to a specified location such as at the doorstep orto a designated neighbor, all based on recipient's instructions.

The highest level of trust attained in these scenarios are basically aphysical signature collected by the shipper, which goes generallyunchecked. At most, the signature is scanned and stored in the shipper'sdatabase.

Others methods include designated private ‘delivery boxes’ provided tothe recipient by a shipper accessible by key, or a delivery box at thelocal post office accessible by a smartcard.

With the huge success of online ordering of products, shippers considerthe usage of automated delivery of packages, for example by drones (e.g.Unmanned Aerial Vehicles (UAVs)). An issue that arises in this contextis that shippers need to prove that a package has been successfullydelivered to a customer. While human delivery personnel (e.g. a mailman)can testify that he has delivered a package, an automated deliverydevice such as a drone cannot do this. Accordingly, approaches aredesirable which allow verification of delivery.

BRIEF DESCRIPTION OF THE DRAWINGS

In the drawings, like reference characters generally refer to the sameparts throughout the different views. The drawings are not necessarilyto scale, emphasis instead generally being placed upon illustrating theprinciples of the invention. In the following description, variousaspects are described with reference to the following drawings, inwhich:

FIG. 1 shows a package ordering and delivery arrangement.

FIG. 2 shows an arrangement at a recipient's house according to variousexamples.

FIG. 3 illustrates a flow for establishing a digital trust relationshipbetween seller, shipper and recipient according to an example.

FIG. 4 illustrates a flow for establishing a digital trust relationshipbetween seller, shipper and recipient according to another example.

FIG. 5 illustrates a flow for establishing a digital trust relationshipbetween seller, shipper and recipient according to another example.

FIG. 6 shows an arrangement for trusted delivery of packages.

FIG. 7 illustrates an example of the approach of establishing a digitaltrust relationship of FIG. 5.

FIG. 8 shows an automated delivery device.

FIG. 9 shows a flow diagram illustrating a method for delivering apackage, for example performed by an automated delivery device.

FIG. 10 shows an automated delivery device 1000 according to variousexamples.

FIG. 11 shows a flow diagram 1100 illustrating a method for delivering apackage, for example performed by an automated delivery device.

DESCRIPTION OF EXEMPLARY IMPLEMENTATIONS

The following detailed description refers to the accompanying drawingsthat show, by way of illustration, specific details and aspects of thisdisclosure in which the invention may be practiced. Other aspects may beutilized and structural, logical, and electrical changes may be madewithout departing from the scope of the invention. The various aspectsof this disclosure are not necessarily mutually exclusive, as someaspects of this disclosure can be combined with one or more otheraspects of this disclosure to form new aspects.

Exemplary embodiments of the present disclosure can be realized by oneor more computers (or computing devices) reading out and executingcomputer-executable instructions recorded on a storage medium (e.g.,non-transitory computer-readable storage medium) to perform thefunctions of one or more of the herein-described embodiment(s) of thedisclosure. The computer(s) may include one or more of a centralprocessing unit (CPU), a microprocessing unit (MPU), or other circuitry,and may include a network of separate computers or separate computerprocessors. The computer-executable instructions may be provided to thecomputer, for example, from a network or the storage medium. The storagemedium may include, for example, one or more of a hard disk, arandom-access memory (RAM), a read-only memory (ROM), a storage ofdistributed computing systems, an optical disk (such as a compact disc(CD), digital versatile disc (DVD), or Blu-ray Disc (BD), a flash memorydevice, a memory card, and the like. By way of illustration, specificdetails and embodiments in which the invention may be practiced aredescribed in the following.

FIG. 1 shows a package ordering and delivery arrangement 100.

A user (customer) 101 living in this house 102 uses his computer 103 toconnect to the server 104 of a seller 105. Typically, the server 104hosts a website accessible via the Internet 110 to which the user 101may connect using his computer 103 and where he may select a product andplace an order for the product. The product is packed into a package 106which is given to a shipper 107 which is tasked to deliver the package106 to the user 101. The shipper 107 uses automated delivery by means ofan automated delivery device 108, e.g. a drone, to deliver the package106 to the user's doorstep 109.

The shipper 107, on behalf of the seller 105, can deliver the package106 to the correct address of the user's house 102 even in an unattendedscenario when using an autonomous system (i.e. the automated deliverydevice 108) delivering the package 106 to the customer's front door(doorstep 109) when the user (customer) 101 is not present to receiveit.

However, this unattended delivery method is typically not trusted byeither side. Neither the sender (shipper 107) nor the recipient (user101) can positively identify each other. This can cause liability issueswhen, for example, the package 106 is delivered to the wrong locationand/or the wrong recipient, or it is stolen or arrives damaged. In suchcases whenever the delivery is unattended, it would be difficult todetermine who is at fault—the shipper 107 or the customer 101. This canalso cause shipper's reputation to be negatively affected.

According to various examples, a method and apparatus for trusted andreliable delivery are provided. A dispatching device (i.e. an automateddelivery device 108) may be configured upon arrival to a drop-off point(e.g. doorstep 109), to collect evidence of delivery such as GPSlocation or photo (image), and to timestamp at the time and place ofdelivery and submit it to a delivery tracking system. A secure enginebased on hardware (such as SGX (Software Guard Extensions), Trustzone,and a co-processor) may be used that collects the data directly from thesensor and signs it thus creating trust between the parties.

This digital trust approach allows securely authenticating two parties(delivery device and recipient) and may be used to establish a trustedrelationship between seller 105, shipper 107 and recipient 101. Thereceiving side (user 101) is, in case of an issue, able to open adispute and use the same approach for providing evidence ofnon-delivery, a broken package, etc. The digital trust approach can beused by both sides to ascertain and validate each side to ensure theintended and accurate origin and destination of the package. This allowsfully automating the delivery process by utilizing an unmannedautonomous (or semi-autonomous) delivery system such as a drone, arobot, an automated smart car or combinations.

FIG. 2 shows an arrangement 200 at the recipient's house according tovarious examples.

An automated delivery device (dispatching device) 201, e.g.corresponding to automated delivery device 108 of FIG. 1, delivers apackage 202 to a drop-off point, e.g. a doorstep 203 of a customer'shouse 204 corresponding to the doorstep 109 of FIG. 1.

The dispatching device 201 may be configured to travel to a locationassociated with a customer, e.g. a customer's house or residence 204.The dispatching device 201, upon arrival at the drop point 203, isfurther configured to collect evidence of the delivery of the package202 such as GPS location and a timestamp at the time of delivery. Thedispatching device 201 may collect the evidence electronically usinghardware, software or both, e.g. using a GPS receiver and a clock. Thedispatching device 201 may further be equipped with a camera 205 and beconfigured to take one or more photos (e.g., digital image(s)) of thedelivered package 202. The dispatching device 201 is configured todeliver the evidence or data thereof, (possibly including thephoto(s)/digital image(s)) through any suitable means (e.g., wirelesscommunications) to a server 206 of the provider of the digital trustservice.

The trust is gained by a secure engine 214 of the dispatching devicewhich may be based on hardware (such as SGX, Trustzone, secureco-processor) that is configured to collect the evidence data directlyfrom the corresponding sensors (GPS receiver 209, camera 205, timer 209)and signs it, e.g. using EPID (Enhanced Privacy ID).

The receiving side, i.e. the customer 101 can, in case of an issue, opena dispute and use a similar method for providing evidence ofnon-delivery or a broken package, etc. For this, the house 204 may beprovided with a camera 207 configured to take a picture of the deliveredpackage.

According to various examples, the camera 207 is used by the dispatchingdevice 201 to strengthen the evidence that it gathers and provides tothe server 206: A controller 210 of the dispatching device 201 may senda command via a transmitter 211 of the dispatching device 201 and areceiver 212 of the camera 207 which instructs the camera 207 to take aphoto of the delivered package 202. The controller 210 may furtherinstruct the camera 207 to upload this photo to the server 206 or toprovide it to the dispatching device 201. In the latter case, thedispatching device 201 may itself upload the photo to the server 206.The controller 210 may for example include one or more microprocessors,microcontrollers or an FPGA (Field Programmable Gate Array) and may beconfigured to execute program instructions and operatively communicatewith other components.

At the customer's location, there may also be provided a wirelessranging device 213 (e.g. a beacon device) that transmits a wirelessbeacon signal that allows the delivery device 201 to more accuratelyfind the drop-off location 203. That is, the delivery device 201 may beconfigured to receive a signal from the beacon device in order to findthe correct drop-off location.

Approaches according to various examples such as described withreference to FIG. 2 allow establishing a digital trust relationshipbetween 105 seller, shipper 107 and recipient 101.

FIG. 3 illustrates a flow for establishing a digital trust relationshipbetween seller, shipper and recipient according to an example.

In 301, the recipient 101 orders a product from the seller 105.

In 302, the seller 105 dispatches the product via the shipper 107.

In 303, the shipper 107 sends package with the product via the automateddelivery device 108, e.g. a UAV (unmanned aerial vehicle).

In 304, the delivery device 108 approaches the recipient's location(e.g. the customer's house 102) via GPS.

In 305, the delivery device 108 performs the package drop-off andauthentication process. In this example, it is assumed that there is noactive device (such as camera 112) at the recipient's house 102. Theprocess of 305 includes 306 to 309 as follows:

In 306, the delivery device 108 identifies precise drop-off location(more precise than GPS, e.g. the customer's doorstep 109) using, forexample, optical recognition (e.g. based on a QR) or a camera-basedidentification of physical premises (building, patio, yard, etc.) basedon one or more recipient-provided reference images. The delivery devicemay also identify the precise drop-off location (more precise than GPS,e.g. the doorstep 203) using the wireless ranging device 213.

In 307, the delivery device 108 drops off the package (e.g. a parcel)106.

In 308, the delivery device 108 takes a picture of the package 106 bymeans of its camera 205. The image or picture, in addition to capturingthe package, may capture other identifiable aspects associated with theaddress or residence of the recipient.

In 309, the delivery device 108 digitally signs the picture andtimestamp information of the delivery time (e.g. using EPID as a key toencrypt) and uploads it through any suitable communication means toserver 206 (e.g. in a cloud).

FIG. 4 illustrates a flow for establishing a digital trust relationshipbetween seller, shipper and recipient according to another example.

In this example, it is assumed that both the delivery device 201 and thedrop-off location 204 have their own camera 205, 212, i.e. there is alsoan on-premise camera.

The following may be carried out in addition to 301 to 309 of FIG. 3.

In 401, at the time of the order, the recipient 101 specifies a way forthe delivery device 108 to communicate with the camera 212 at therecipient's location. For example, such a mechanism could use aBluetooth device address to identify the camera 212. Alternatively,Infrared communication may be used.

In 402, when the delivery device 108 has dropped-off the package 106, itsignals the recipient's camera 212.

In 403, the recipient's camera 212, in response, also takes a picture ofthe delivered package, digitally signs the picture and timestampinformation specifying the time of the picture and uploads it to theserver 206.

FIG. 5 illustrates a flow for establishing a digital trust relationshipbetween seller, shipper and recipient according to another example.

In this example, a full mutual authentication is carried out.

In 501, the recipient 101 orders a product from the seller 105.

In 502, the seller 105 dispatches the product via the shipper 107.

In 503, the shipper 107 sends package via the automated delivery device108, 201, e.g. a UAV.

In 504, the delivery device 201 identifies the precise drop-off location(more precise than GPS, e.g. the doorstep 203) using the wirelessranging device 213. The customer may provide information identifying thewireless ranging device 213 at the time of order in 501. That is, thecustomer may electronically transmit the information identifying thewireless ranging device 213 which is electronically communicated to thedelivery device 201.

For example, the delivery device 201 may use Wi-Fi based FTM (FineTiming Measurement) according to IEEE, with the delivery device 201being the initiator, and one or more responders located at therecipient's site (corresponding to one or more wireless ranging devices213). In this case, the information identifying the wireless rangingdevice 213 would e.g. be the BSSID (Basic Service Set Identifier) and/orthe SSID (Service Set Identifier).

In 505, the delivery device 201 and the wireless ranging device 213mutually authenticate each other using a trust relationship establishedat the time of sale or shipment, for example. For example, at the timeof sale 501, a token (such as a random passphrase) is assigned for thistransaction and distributed to both the delivery device 201 and thewireless ranging device 213, e.g. by the server 206. For example, thedelivery device 201 and the wireless ranging device 213 can mutuallyverify this token using the SAE (Secure Authentication of Equals) Wi-Fiprotocol. Both can verify each other's possession of the Token, and canalso use it to exchange temporal keys for further secure communicationsif necessary. An authentication handshake can use the same WirelessRadio used for the Wireless Ranging of 504. For example, in the case ofWi-Fi based FTM, the delivery device 201 could use the same FTMresponder's Wi-Fi radio for communication.

It should be noted that a continuous output of the wireless rangingdevice 213 can be used to geo-fence the authentication to prevent asituation where the delivery device 201 is in wireless range of thewireless ranging device 213 but in the wrong location or too far awayfrom the recipient due to errors or attacks in 504. For example, anattacker could fake an unauthenticated high-power ranging signal andturn it off with the beginning of authentication in 505, resulting inauthentication succeeding with the correct wireless ranging device 213within wireless range but in a different unintended drop-off location.

In 506, the delivery device 201 drops off the package 202 at the preciseintended and authenticated location.

In 507, optionally, one or both sides take one or more pictures of thedelivered package 202, embed the ranging information and authenticationresults into the picture's metadata, and send it to the server 206 (e.g.acting as a Trusted Electronic Notary) as proof of delivery and damageidentification. On the customer's side, this may be performed by asystem including the camera 212 and/or the wireless ranging device 213.

The delivery device 201 and the customer's system may would follow theprocessing of SGX (Trusted Execution Environment) as illustrated in FIG.6 to sign the picture, timestamp and location information to securelycommunicate with the server 206.

FIG. 6 shows an arrangement 600 for trusted delivery of packages.

The arrangement 600 includes a recipient device 601, for examplecorresponding to the customer's system including camera 212 and wirelessranging device 213, a dispatching device 602, for example correspondingto the delivery device 201, a service provider's server 603, for examplecorresponding to the server 206 and a verification authority 604.

The recipient device 601 has a camera 605 and a positioning device 606providing its location. Further, the recipient device 601 has a TEE(Trusted Execution Environment) attestation engine 607 and a deliveryverifier 608.

The camera 605 provides an image of a delivered package to the TEEattestation engine 607 and the positioning device 606 gives anindication of the position of the recipient device 601 at the time oftaking the image to the TEE attestation engine 607.

The TEE attestation engine 607 checks and validates the deliveryverifier 608, e.g. software running on the recipient device 601implementing the delivery verifier 608, and the delivery verifier 608transmits the image and the indication of the position of the recipientdevice 601 to the service provider 603. The TEE attestation engine 607may be implemented by a secure root of the TEE attestation engine 607which may be verified by the verification authority 604.

Similarly, the dispatching device 602 has a camera 609, a positioningdevice 610 providing its location, a TEE (Trusted Execution Environment)attestation engine 611 and a delivery confirmation agent 612.Furthermore, the dispatching device 602 has in this example a timer 113.

The camera 609 provides an image of a delivered package to the TEEattestation engine 611 and the positioning device 610 gives anindication of the position of the recipient device 602 at the time oftaking the image to the TEE attestation engine 611. The timer providesan indication of this time to the TEE attestation engine 611.

The TEE attestation engine 611 checks and validates the deliveryconfirmation agent 612, e.g. software running on the recipient device602 implementing the delivery confirmation agent 612, and the deliveryconfirmation agent 612 transmits the image and the indications of theposition of the recipient device 601 and the time to the serviceprovider 603.

FIG. 7 illustrates an example of the approach of establishing a digitaltrust relationship of FIG. 5.

The example involves a user 701 having a computer 702, a recipientdevice 703 and a home 704, a service provider 705, a shipper 706 and adelivery device 707. In this example, the service provider 705 providingthe service of establishing trust of delivery is also the seller.

In 708, the user 701 orders a package from the service provider 705(seller).

In 709, the service provider 705 confirms the order and generates atoken (e.g. a random passphrase).

In 710 the user's computer 702 and the service provider 705 sharedetails about the token as well as about the recipient device 703 (e.g.its support of WiFi based FTM and corresponding details).

In 711, the user 701 approves or sets the recipient and package deliverydetails and configures the recipient device 703 accordingly.

In 712, the recipient device 703 constantly monitors changes in theshipment or updates package delivery information for any changes orre-scheduling.

In 713, the service provider provides package details (such as deliveryaddress) to the delivery device 707 by means of the shipper 706.

In 714, the delivery device 707 identifies the precise drop-off location(with higher precision than provided by GPS) using a wireless rangingsystem (such as WiFi based FTM).

In 715, the delivery device 707 and the recipient device 703 mutuallyauthenticate themselves using the token assigned with the order.

In 716, the shipper leaves the package at the drop-off location.

In 717, the delivery device 707 and the recipient device 703 take aphoto of the delivered package and send it to a cloud-based E-notary(e.g. provided by the service provider 705) which timestamps anddigitally signs the pictures for proof of delivery.

In summary, according to various examples, an automated delivery deviceis provided as illustrated in FIG. 8.

FIG. 8 shows an automated delivery device 800.

The automated delivery device 800 includes a transportation system 801configured to move a package to a package recipient location and apackage drop-off mechanism 802 configured to drop off the package at thepackage recipient location.

Further, the automated delivery device 800 includes a communicationsystem 803 configured to communicate with a recipient camera device atthe package recipient location and a controller 804 configured toinstruct the recipient camera device via the transceiver to verifypackage delivery based on an image of the delivered package.

According to various examples, in other words, an automated (andtypically unmanned) delivery device, such as a drone or generally arobot, instructs a camera at a drop-off point to take a photo of thedelivered package (i.e. package) to verify delivery of the package. Thecamera at the drop-off point may electronically provide the photo to theautomated delivery device or may itself electronically provide the phototo a delivery verification entity such as a server of a service providerproviding a delivery verification service.

The transportation system may include one or more rotors, wheels, tracksetc.

The components of the automated delivery device (e.g. the communicationsystem, and the controller) may for example be implemented by one ormore processors. A “processor” may be understood as any kind of a logicimplementing entity, which may be special purpose circuitry or aprocessor executing software stored in a memory, firmware, or anycombination thereof. Thus a “processor” may be a hard-wired logicprocessor or a programmable logic processor such as a programmableprocessor, e.g. a microprocessor. A “processor” may also be a processorexecuting software, e.g. any kind of computer program. Any other kind ofimplementation of the respective functions which will be described inmore detail below may also be understood as a “processor”. Thecommunication system may for example be at least partially beimplemented by a transceiver which may for example be at least partiallyimplemented by a modem, a baseband processor or other transceivercomponents or also by an application processor.

FIG. 9 shows a flow diagram 900 illustrating a method for delivering apackage, for example performed by an automated delivery device.

In 901, the automated delivery device moves a package to a packagerecipient location.

In 902, the automated delivery device drops off the package at thepackage recipient location.

In 903, the automated delivery device communicates with a recipientcamera device at the package recipient location.

In 904, the automated delivery device instructs the recipient cameradevice to verify package delivery based on an image of the deliveredpackage.

FIG. 10 shows an automated delivery device 1000 according to variousexamples.

The automated delivery device 1000 includes a transportation system 1001configured to move a package to a package recipient location and acommunication system 1002 configured to communicate with a recipientranging device at the package recipient location.

The automated delivery device 1000 further includes a controller 1003configured to verify that the automated delivery device has moved to thecorrect package recipient location based on data received by thecommunication system from the recipient ranging device.

Further, the automated delivery device 1000 includes a package drop-offmechanism 1004 configured to drop off the package at the packagerecipient location if the automated delivery device has moved to thecorrect package recipient location.

FIG. 11 shows a flow diagram 1100 illustrating a method for delivering apackage, for example performed by an automated delivery device.

In 1101, the automated delivery device moves a package to a packagerecipient location.

In 1102, the automated delivery device communicates with a recipientranging device at the package recipient location.

In 1103, the automated delivery device verifies that the automateddelivery device has moved to the correct package recipient locationbased on data received by the communication system from the recipientranging device.

In 1004, the automated delivery device drops off the package at thepackage recipient location if the automated delivery device has moved tothe correct package recipient location.

The following examples pertain to further exemplary implementations.

Example 1 is an automated delivery device as illustrated in FIG. 8.

In Example 2, the subject-matter of Example 1 may optionally include afurther camera system configured to obtain a further image of thedelivered package.

In Example 3, the subject-matter of Example 2 may optionally include thecontroller being configured to upload the further image to a deliveryverification server.

In Example 4, the subject-matter of any one of Examples 2-3 mayoptionally include the controller being configured to upload the furtherimage to a delivery verification server with a timestamp of the drop offof the package.

In Example 5, the subject-matter of any one of Examples 1-4 mayoptionally include the communication system being radio system.

In Example 6, the subject-matter of any one of Examples 1-5 mayoptionally include the communication system being configured tocommunicate with a recipient ranging device and the controller beingconfigured to verify that the automated delivery device has moved to thecorrect package recipient location based on data received by thecommunication system from the recipient ranging device.

In Example 7, the subject-matter of Example 6 may optionally include therecipient ranging device being a beacon device.

In Example 8, the subject-matter of any one of Examples 1-7 mayoptionally include the communication system being configured tocommunicate with a recipient authentication device and the controllerbeing configured to verify that the automated delivery device has movedto the correct package recipient location based on data received by thecommunication system from the recipient authentication device.

In Example 9, the subject-matter of Example 8 may optionally include thecontroller being configured to verify that the automated delivery devicehas moved to the correct package recipient location based on averification that the recipient authentication device has possessionabout a previously negotiated token.

In Example 10, the subject-matter of any one of Examples 1-9 mayoptionally include the controller being configured to instruct therecipient camera device to obtain the image of the delivered package andupload it to a delivery verification server.

In Example 11, the subject-matter of any one of Examples 1-10 mayoptionally include the controller being configured to instruct therecipient camera device to obtain the image of the delivered package andtransmit it to the automated delivery device.

In Example 12, the subject-matter of any one of Examples 1-11 mayoptionally include the delivery device being an unmanned aerial vehicle.

In Example 13, the subject-matter of any one of Examples 1-12 mayoptionally include the controller being implemented by a secure embeddedcontroller.

Example 14 is a method for delivering a package as illustrated in FIG.9.

In Example 15, the subject-matter of Example 14 may optionally includethe package being moved to the package recipient location by means of anautomated delivery device and obtaining a further image of the deliveredpackage by means of a camera of the automated delivery device.

In Example 16, the subject-matter of Example 15 may optionally includeuploading the further image to a delivery verification server.

In Example 17, the subject-matter of any one of Examples 15-16 mayoptionally include uploading the further image to a deliveryverification server with a timestamp of the drop off of the package.

In Example 18, the subject-matter of any one of Examples 14-17 mayoptionally include communicating with the recipient camera device bymeans of a radio system.

In Example 19, the subject-matter of any one of Examples 14-18 mayoptionally include communicating with a recipient ranging device andverifying that the package has been moved to the correct packagerecipient location based on data received by the communication systemfrom the recipient ranging device.

In Example 20, the subject-matter of Example 19 may optionally includethe recipient ranging device being a beacon device.

In Example 21, the subject-matter of any one of Examples 14-20 mayoptionally include communicating with a recipient authentication deviceand verifying that the package has been moved to the correct packagerecipient location based on data received by the communication systemfrom the recipient authentication device.

In Example 22, the subject-matter of Example 21 may optionally includeverifying that the package has been moved to the correct packagerecipient location based on a verification that the recipientauthentication device has possession about a previously negotiatedtoken.

In Example 23, the subject-matter of any one of Examples 14-22 mayoptionally include instructing the recipient camera device to obtain theimage of the delivered package and upload it to a delivery verificationserver.

In Example 24, the subject-matter of any one of Examples 14-23 mayoptionally include the package being moved to the package recipientlocation by means of an automated delivery device and instructing therecipient camera device to obtain the image of the delivered package andtransmit it to the automated delivery device.

In Example 25, the subject-matter of any one of Examples 14-24 mayoptionally include the package being moved to the package recipientlocation by means of an unmanned aerial vehicle.

In Example 26, the subject-matter of any one of Examples 14-25 mayoptionally include instructing of the recipient camera device to verifypackage delivery based on an image of the delivered package beingperformed by a secure embedded controller.

Example 27 is an automated delivery device as illustrated in FIG. 10.

In Example 28, the subject-matter of Example 27 may optionally includethe communication system being radio system.

In Example 29, the subject-matter of any one of Examples 27-28 mayoptionally include the recipient ranging device being a beacon device.

In Example 30, the subject-matter of any one of Examples 27-29 mayoptionally include the recipient ranging device comprising a recipientauthentication device and the controller being configured to verify thatthe automated delivery device has moved to the correct package recipientlocation based on a verification that the recipient authenticationdevice has possession about a previously negotiated token.

In Example 31, the subject-matter of any one of Examples 27-30 mayoptionally include the delivery device being an unmanned aerial vehicle.

In Example 32, the subject-matter of any one of Examples 27-31 mayoptionally include the controller being implemented by a secure embeddedcontroller.

Example 33 is a method for delivering a package as illustrated in FIG.11.

In Example 34, the subject-matter of Example 33 may optionally includecommunicating with the recipient ranging device by means of a radiosystem.

In Example 35, the subject-matter of any one of Examples 33-34 mayoptionally include the recipient ranging device being a beacon device.

In Example 36, the subject-matter of any one of Examples 33-35 mayoptionally include the recipient ranging device comprising a recipientauthentication device and verifying that the automated delivery devicehas moved to the correct package recipient location based on averification that the recipient authentication device has possessionabout a previously negotiated token.

In Example 37, the subject-matter of any one of Examples 33-36 mayoptionally include the package being moved to the package recipientlocation by means of an unmanned aerial vehicle.

In Example 38, the subject-matter of any one of Examples 33-37 mayoptionally include the verifying being performed by a secure embeddedcontroller.

It should be noted that one or more of the features of any of theexamples above may be combined with any one of the other examples.

While specific aspects have been described, it should be understood bythose skilled in the art that various changes in form and detail may bemade therein without departing from the spirit and scope of the aspectsof this disclosure as defined by the appended claims. The scope is thusindicated by the appended claims and all changes which come within themeaning and range of equivalency of the claims are therefore intended tobe embraced.

1. A ground transporter, configured to: transport a package to a packagerecipient location; receive a token from a token recipient, whereinreceiving the token represents a verification that the groundtransporter has moved to the package recipient location; and wherein theground transporter is configured, if the token is received, to deliverthe package at the package recipient location.
 2. The ground transporterof claim 1, wherein the ground transporter is configured to authenticatethe recipient using the token.
 3. The ground transporter of claim 2,wherein authenticating the device using the token comprises the groundtransporter comparing the token to a predetermined token.
 4. The groundtransporter of claim 1, wherein the ground transporter is an autonomousvehicle.
 5. The ground transporter of claim 1, wherein the token is apassphrase.
 6. The ground transporter of claim 1, wherein the token is apreviously negotiated token, and wherein ground transporter is furtherconfigured to verify that the ground transporter has moved to thecorrect package recipient location based on a verification that therecipient has possession of the token.
 7. The ground transporter ofclaim 1, wherein the ground transporter is configured to receive thetoken from a recipient device using a Secure Wireless Protocol.
 8. Theground transporter of claim 7, wherein the Secure Wireless Protocol is aSecure Authentication of Equals Protocol according to the Wi-FiAlliance.
 9. The ground transporter of claim 1, wherein delivering thepackage at the package recipient location comprises leaving the packageat the package receipt location.
 10. The ground transporter of claim 1,wherein the ground transporter comprises a camera system, configured toobtain an image of the delivered package.
 11. The ground transporter ofclaim 10, wherein the ground transporter is further configured tocontrol the transmitter to wirelessly send the image of the deliveredpackage.
 12. A non-transitory computer readable medium, comprisinginstructions, which, if executed cause one or more processors to:control a ground transporter to transport a package to a packagerecipient location; receive a token from a recipient, wherein receipt ofthe token represents a verification that the ground transporter hasmoved to the package recipient location; and if the ground transporterreceives the token, control the ground transporter to deliver thepackage at the package recipient location.
 13. The non-transitorycomputer readable medium of claim 12, wherein the instructions arefurther configured to cause the one or more processors to authenticatethe recipient using the token.
 14. The non-transitory computer readablemedium of claim 13, wherein authenticating the recipient using the tokencomprises comparing the token to a predetermined token.
 15. Thenon-transitory computer readable medium of claim 12, wherein the groundtransporter is an autonomous vehicle.
 16. The non-transitory computerreadable medium of claim 12, wherein the token is a passphrase.
 17. Thenon-transitory computer readable medium of claim 12, wherein the tokenis a previously negotiated token, and wherein the instructions arefurther configured to cause the one or more processors to verify thatthe ground transporter has moved to the correct package recipientlocation based on a verification that the recipient has possession ofthe previously negotiated token.
 18. The non-transitory computerreadable medium of claim 12, wherein the instructions are furtherconfigured to cause the one or more processors to control a transceiverto receive the token from a recipient device using a Secure WirelessProtocol.
 19. The non-transitory computer readable medium of claim 18,wherein the Secure Wireless Protocol is a Secure Authentication ofEquals Protocol according to the Wi-Fi Alliance.
 20. The non-transitorycomputer readable medium of claim 12, wherein delivering the package atthe package recipient location comprises leaving the package at thepackage receipt location.